harden: vector security audit fixes - #115
Merged
Merged
Conversation
VSIM's COUNT and EF_SEARCH parameters accepted unbounded u64 values, allowing a single request like `VSIM key 0.1 COUNT 999999999999` to cause immediate OOM by attempting to allocate a massive results vector. - add MAX_VSIM_COUNT (10,000) — generous for any practical similarity search while preventing memory exhaustion - add MAX_VSIM_EF (1,024) — consistent with VADD's MAX_HNSW_PARAM, prevents worst-case O(n) graph traversal
- replace unreachable!() in vrem with proper WrongType error return - use saturating arithmetic in vadd memory estimate to prevent overflow from bypassing memory limits - use saturating_mul in VectorSet::memory_usage() to prevent overflow in tracking calculations - improve VectorSet::clone fallback chain — adds intermediate fallback layers before last-resort panic, with tracing::error logging - guard search result consistency with min() on key/distance lengths
a crafted AOF or snapshot file could specify dimension=4 billion, causing the recovery loop to iterate 4B times and exhaust memory despite capped_capacity limiting the initial allocation. - add MAX_PERSISTED_VECTOR_DIMS (65,536) and MAX_PERSISTED_VECTOR_COUNT (10M) constants in format.rs - reject AOF records with dim > MAX_PERSISTED_VECTOR_DIMS - reject snapshot entries with dim or count exceeding limits - validate metric (0-2) and quantization (0-2) enum values in snapshot deserialization to catch corruption early - add FormatError::InvalidData variant for structured error reporting
21 tests covering VADD, VSIM, VREM, VGET, VCARD, VDIM, VINFO parsing including edge cases: wrong arity, exceeding limits, unknown options.
kacy
force-pushed
the
harden-vector-security
branch
from
February 14, 2026 14:44
3058f48 to
05820b4
Compare
kacy
added a commit
that referenced
this pull request
Feb 19, 2026
* harden: cap VSIM COUNT and EF parameters VSIM's COUNT and EF_SEARCH parameters accepted unbounded u64 values, allowing a single request like `VSIM key 0.1 COUNT 999999999999` to cause immediate OOM by attempting to allocate a massive results vector. - add MAX_VSIM_COUNT (10,000) — generous for any practical similarity search while preventing memory exhaustion - add MAX_VSIM_EF (1,024) — consistent with VADD's MAX_HNSW_PARAM, prevents worst-case O(n) graph traversal * harden: fix panics and overflows in vector operations - replace unreachable!() in vrem with proper WrongType error return - use saturating arithmetic in vadd memory estimate to prevent overflow from bypassing memory limits - use saturating_mul in VectorSet::memory_usage() to prevent overflow in tracking calculations - improve VectorSet::clone fallback chain — adds intermediate fallback layers before last-resort panic, with tracing::error logging - guard search result consistency with min() on key/distance lengths * harden: validate vector dimensions and counts in persistence a crafted AOF or snapshot file could specify dimension=4 billion, causing the recovery loop to iterate 4B times and exhaust memory despite capped_capacity limiting the initial allocation. - add MAX_PERSISTED_VECTOR_DIMS (65,536) and MAX_PERSISTED_VECTOR_COUNT (10M) constants in format.rs - reject AOF records with dim > MAX_PERSISTED_VECTOR_DIMS - reject snapshot entries with dim or count exceeding limits - validate metric (0-2) and quantization (0-2) enum values in snapshot deserialization to catch corruption early - add FormatError::InvalidData variant for structured error reporting * test: add vector command parser tests 21 tests covering VADD, VSIM, VREM, VGET, VCARD, VDIM, VINFO parsing including edge cases: wrong arity, exceeding limits, unknown options.
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
summary
security audit of the vector similarity search code (HNSW via usearch, PRs #95-96) identified the likely root cause of the VM OOM/hang and several other vulnerabilities across all crates.
root cause of OOM: VSIM's
COUNTandEFparameters accepted unbounded u64 values. a singleVSIM key 0.1 COUNT 999999999999request could exhaust all available memory.fixes by crate
ember-protocol
emberkv-core
unreachable!()in vrem with proper error returnember-persistence
what was tested
design considerations
the VSIM COUNT cap of 10,000 is generous for any practical similarity search (most applications use k=10-100). this prevents the OOM vector while not limiting legitimate usage. the persistence caps match the protocol-layer limits for consistency.